[レポート] ANT383 – Teradata から Amazon Redshift への移行: マクドナルドのベストプラクティス #reinvent

AWS re:Invent 2018

#ビッグデータ

#AWS Database Migration Service

#Amazon Redshift

#AWS

石川覚

2018.12.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

ANT383 - Migrate from Teradata to Amazon Redshift: Best Practices with McDonald's のセッションのレポートとなります。

Migrate from Teradata to Amazon Redshift: Best Practices with McDonald's (ANT383) - AWS re:Invent 2018 from Amazon Web Services

セッション概要

Modernizing your data warehouse can unlock new insights while substantially improving query and data load performance, increasing scalability, and saving costs. In this chalk talk, we discuss how to leverage the AWS Database Migration Service and AWS Schema Conversion Tool to migrate from Teradata to Amazon Redshift. McDonald's joins us to share their migration journey, after which they were able to run ~7,000 reports across four AWS Regions, enabling new reporting capabilities for marketing, franchises, supply chain, pricing, and many more business units.

このchalk talkでは、AWS Database Migration Service と AWS Schema Conversion Tools を活用してTeradataからAmazon Redshiftに移行する方法について説明します。 McDonald'sは移行期間を共有するために私たちに加わりました。その後、マーケティング、フランチャイズ、サプライチェーン、価格設定、さらに多くのビジネスユニットのための新しいレポート機能を実現するために、4つのAWSリージョンで約7000のレポートを実行することができました。

スピーカー

Without Data you are just another person with an opinion.

「データがなければ、それはただの意見に過ぎない」

　ー W・エドワーズ・デミング

移行前〜私たちが持っていたもの...

メインDWプラットフォームとしてのTeradata
ETLツールとしてのDataStage
BIアプリケーションとしてのMicroStrategy
Tableauとその他のレポートツール。
その他のデータベースは、 Oracle、MS-SQL Server
Hadoopはいくつかの作業負荷を処理するために使用

目標〜どこに行きたいの？

現状

サイロ化されたデータ - 限られたデータ可用性
リソース集約型 - データを取得するには数週間から数か月かかる
データ要求が迅速で固定コストが高いため、規模が限定されている
何が起こったかに焦点を当てた記述的な分析
ITはデータを収集し維持する

目標

統合された信頼できるデータマーケットプレース
セルフサービス配信 - 数時間/日に改善する
オンデマンドでスケールするクラウド、使用量ベースのコスト
Descriptive（記述的）、Predictive（予測的）、Prescriptive（処方的）な分析
ITはビジネスの洞察を可能にする

移行の理由〜なぜ移行したのか？

データの爆発（ほぼ毎年2倍） - 顧客中心
セルフサービスデータ分析に対するより多くの要望
ユースケースのさらなる複雑化
- リアルタイムデータ、構造化データ、非構造化データ等のブレンド
- データエンジンタイプの柔軟性が制限
スキーマ変更の処理時間が遅くなる
インフラストラクチャのスケーリングが制限されている
バックアップおよび障害復旧ソリューションの欠如
グローバルに展開できない - データ分析の現場ではより多くのデータ保護法が登場

移行のステップ

現在の状況、コスト、機能、データ量を評価する
- 取引、運営、サプライチェーン、顧客、財務、参照
オンプレミスのソリューションに存在する課題を理解
移行するオプションの計画を立てる
- AWSに最適化して移行する
- Lift and shiftと最適化する
- 上記の両方とも長所と短所がある
移行するすべての資産をカタログ化する
移行計画を策定してすべての関係者と調整する
さまざまなプラットフォームのオプションを鑑みてAWSに決断

移行オプションの比較

Option Cは、現行TeradataをAWSにLiftした構成で、スコアは現在と代わりません。Option DとOption EはAWSに最適化したEMR+Redshift移行方式です。両者の違いはインスタンスを事前購入するリザーブドインスタンスするか否かです。最終的には一番スコアの高いOption Eが採用されました。

Option A : オンプレミスのTeradata（現状をベースラインとする）
Option C : AWS（EC2）のTeradata
Option D : AWSのEMR、Redshift（オンデマンドインスタンス）
Option E : AWSのEMR、Redshift（リザーブドインスタンス）

スケジュールプラン

学び

文化の変化 - Teradataでどうしていたかを忘れてしまう
ワークロードの早い段階でデータエンジンを試す
社内のキーマンをトレーニングして、AWS認定パートナーを選び、AWS化を推進する
手動作業のスピードアップと軽減のために、移行ツールを使用する
最初に見積もったパフォーマンス特性よりも様々なパフォーマンス特性を考慮する
必要に応じて使うと混沌となるので事前準備を怠らない
- Amazon Redshiftは現在、必要に応じてワークロードを追加するとうまく動作しない
適切な管理ツールがあることを確認する：
- インフラストラクチャ管理、セキュリティ、キャパシティプランニング
- 利用状況と請求/コスト配分
- データ管理

最後に

Redshiftに移行する際には、必ず「AWSに最適化して移行」か「Lift and shiftを前提とした最適化」のどちらか迷うわけですが、両方とも長所と短所がありどちらが正解とは言い切れません。仮に最終的なゴールが「AWSに最適化して移行」だとしても内部的には「Lift and shiftを前提とした最適化」のフェーズを分けたほうが潜在的な問題点の洗い出しに効果的です。また、移行方法に触れられていませんが、AWSが無料で提供しているSCT（Schema Conversion Tools）は、TeradataからRedshiftへスキーマの変換やデータのエクスポートができますので、Teradataからの移行の際にはご利用をご検討ください。